Trinity のパフォーマンスモニタリング機能を Apptainer で動く Trinity コンテナで試してみた
2024.05.24Triity には解析実行中のリソースの使用率レポートを出力できるオプション（--monitoring）があります。
Apptainer で起動する Trinity コンテナでも利用可能か試してみました。
Trinity Runtime Profiling · trinityrnaseq/trinityrnaseq Wiki
検証環境
Trinityの実行環境と設定
検証に使用した AWS ParallelCluster のバージョンとコンピュートノードのスペックは以下の通りです。
| 項目 | 値 |
|---|---|
| AWS ParallelCluster | 3.9.1 |
| OS | Ubuntu 22.04 |
| Compute Node | c6id.4xlarge |
| CPU | 8 core |
| Memory | 32 GB |
| Simultaneous Multi-Threading | 無効 |
Trinity のバージョンは以下の通りです。Apptainer コンテナで実行しました。
| 項目 | 値 |
|---|---|
| Trinity | v2.15.1 |
Trinity を実行してみる
Trinity の実行コマンドに --monitoring オプションを指定して実行します。
このオプションを指定することで CPU、メモリ、ディスク I/O の使用状況を一定間隔で取得し、ファイル（collectl.dat）に書き出し、後から確認できるとのことです。
実行スクリプト全文
スクリプトは長いですが--monitoringの指定が今回のポイントです。
#! /bin/bash
#SBATCH -p p4
#SBATCH -N 1
#SBATCH --cpus-per-task=8
#SBATCH -J "test-ebs"
INSTANCE_CPU=8
INSTANCE_MEM=32
MOUNT_PATH="/mnt"
IMAGE_PATH="/mnt/s3-readonly/images"
USE_IMAGE="trinityrnaseq.v2.15.1.simg"
READ_FILE_PATH="/mnt/s3-readonly/reads"
LEFT_FILE="L1_R1.fastq"
RIGHT_FILE="D1_R1.fastq"
OUTPUT_PATH="/work"
SAVE_PATH="/home/ubuntu/results/"
# SLURM変数のデフォルト値設定
SLURM_JOB_NAME=${SLURM_JOB_NAME:-"default-job-name"}
SLURM_JOB_ID=${SLURM_JOB_ID:-"default-id"}
# /scratchディレクトリが存在しない場合は作成する
if [ ! -d "${OUTPUT_PATH}" ]; then
echo "Create Directory"
sudo mkdir -p "${OUTPUT_PATH}"
sudo chown ubuntu. "${OUTPUT_PATH}"
shdo chmod 777 "${OUTPUT_PATH}"
fi
# 出力結果保存先ディレクトリが存在しない場合は作成する
if [ ! -d "${SAVE_PATH}" ]; then
sudo mkdir -p "${SAVE_PATH}"
fi
# Trynity実行
apptainer exec --bind ${MOUNT_PATH}:/mnt --bind ${OUTPUT_PATH}:${OUTPUT_PATH} \
-e ${IMAGE_PATH}/${USE_IMAGE} \
Trinity \
--seqType fq \
--single ${READ_FILE_PATH}/${LEFT_FILE},${READ_FILE_PATH}/${RIGHT_FILE} \
--CPU ${SLURM_CPUS_PER_TASK} \
--max_memory ${INSTANCE_MEM}G \
--monitoring \
--output ${OUTPUT_PATH}/${SLURM_JOB_NAME}-${SLURM_JOB_ID}/trinity_out_dir
# 出力結果のディレクトリをtarで固める
tar -zcf ${SLURM_JOB_NAME}-${SLURM_JOB_ID}.tar.gz -C ${OUTPUT_PATH} ${SLURM_JOB_NAME}-${SLURM_JOB_ID}
# 出力結果のディレクトリを永続ストレージへ退避
mkdir -p ${SAVE_PATH}
mv ${SLURM_JOB_NAME}-${SLURM_JOB_ID}.tar.gz ${SAVE_PATH}
実行結果確認
実行結果はTrinity.timingファイルから確認しました。このファイルからはオプションで--monitoring指定していたことはわかりますが、collectl の情報はありませんでした。
Statistics: =========== Trinity Version: Trinity-v2.15.1 Compiler: GCC Trinity Parameters: --seqType fq --single /mnt/s3-readonly/reads/L1_R1.fastq,/mnt/s3-readonly/reads/D1_R1.fastq --CPU 8 --max_memory 32G--monitoring --output /work/test-ebs-46/trinity_out_dir Unpaired read mode Input data Single.fasta 78 MByte Number of unique KMERs: 12092362 Number of reads: 659537 Output data Trinity.fasta 0 MByte Runtime ======= Start: Sun May 12 08:50:49 UTC 2024 End: Sun May 12 09:09:36 UTC 2024 Trinity 1127 seconds Inchworm (phase 1 - read clustering) 20 seconds Chrysalis (phase 1 - read clustering) 1076 seconds Rest (phase 2 - parallel assembly) 31 seconds
スクリプトを実行したカレントディレクトリと同ディレクトリにcollectlという名前のディレクトリが作成されていました。その中にはcollectl.datが 1 つ保存されていました。
$ ls -l total 4 drwxrwxr-x 2 ubuntu ubuntu 4096 May 12 08:50 collectl $ ls -l collectl total 204 -rw-rw-r-- 1 ubuntu ubuntu 204800 May 12 09:09 collectl.dat
ファイルの中身は生データが保存されています。人間でも見やすいようにレポート変換コマンドを試してみます。
$ head -n 3 collectl.dat 20240512 08:51:52 4587 ubuntu 20 4567 0 S 14M 11M 0 0.02 0.01 0 00:00.09 0 20K 0 35 perl /usr/local/bin/Trinity--seqType fq --single /mnt/s3-readonly/reads/L1_R1.fastq,/mnt/s3-readonly/reads/D1_R1.fastq --CPU 8 --max_memory 32G --monitoring --output/work/test-ebs-46/trinity_out_dir 20240512 08:51:52 4708 ubuntu 20 4704 0 S 3M 1M 6 0.00 0.00 0 00:00.00 0 0 0 0 grep -E Trinity|trinityrnaseq|Inchworm|Chrysalis|Butterfly|jellyfish|samtools|sort|bowtie 20240512 08:51:52 4916 ubuntu 20 4587 0 S 2M 1M 6 0.00 0.00 0 00:00.00 0 0 0 2 sh -c /usr/local/bin/Chrysalis/bin/ReadsToTranscripts -i /work/test-ebs-46/trinity_out_dir/single.fa -f /work/test-ebs-46/trinity_out_dir/chrysalis/bundled_iworm_contigs.fasta -o /work/test-ebs-46/trinity_out_dir/chrysalis/readsToComponents.out -t 8 -max_mem_reads 50000000 -p 10 2>tmp.4587.1715503903.stderr
collectl.dat をレポートへ変換
Trinity の実行コマンドはコンピュートノードの Apptainer 上で起動した Trinity コンテナから実行していました。レポート変換は重たい処理ではないため、ヘッドノードの Apptainer 上で Trinity コンテナを起動してレポート変換を試みます。
実行
レポート変換スクリプトのexamine_resource_usage_profiling.plは、Trinity コンテナの/usr/local/bin/trinity-plugins/COLLECTL/examine_resource_usage_profiling.plにありました。
コマンドの引数はベタ書きで以下のコマンドをcollectlディレクトリに対して実行しました。
$ apptainer exec -e /mnt/s3-readonly/images/trinityrnaseq.v2.15.1.simg /usr/local/bin/trinity-plugins/COLLECTL/examine_resource_usage_profiling.pl collectl/ CMD: /usr/local/bin/trinity-plugins/COLLECTL/util/collectl_dat_to_time_matrix.py --dat collectl//collectl.dat --out_prefix collectl Done. See output files: ['collectl.mem_usage.matrix', 'collectl.cpu_usage.matrix', 'collectl.IO_usage.matrix'] CMD: /usr/local/bin/trinity-plugins/COLLECTL/util/plot_time_vs_resource.Rscript collectl null device
collectlディレクトリと同階層に 4 つのファイルが作成されました。
$ ls -l total 24 drwxrwxr-x 2 ubuntu ubuntu 4096 May 12 08:50 collectl -rw-rw-r-- 1 ubuntu ubuntu 850 May 23 07:50 collectl.IO_usage.matrix -rw-rw-r-- 1 ubuntu ubuntu 533 May 23 07:50 collectl.cpu_usage.matrix -rw-rw-r-- 1 ubuntu ubuntu 919 May 23 07:50 collectl.mem_usage.matrix -rw-rw-r-- 1 ubuntu ubuntu 6326 May 23 07:50 collectl.plot.pdf
*.matrixファイルは人間が見るには早かったです。
$ cat collectl.cpu_usage.matrix time Trinity GraphFromFasta Butterfly BubbleUpClustering samtools 0.0002777777777777778 1 0 0 0 0 0.016666666666666666 9 1 4 0 0 0.03333333333333333 9 0 1 0 0 0.05 9 4 2 0 0 0.06666666666666667 9 0 3 0 0 0.08333333333333333 8 3 0 0 0 0.1 9 0 2 0 0 0.11666666666666667 10 0 1 0 0 0.13333333333333333 9 4 0 0 0 0.15 9 0 2 0 0 0.16666666666666666 9 1 3 0 0 0.18333333333333332 9 5 0 0 0 0.2 9 0 3 1 0 0.21666666666666667 9 0 5 0 0 0.23333333333333334 9 3 0 0 0 0.25 10 0 5 1 0 0.26666666666666666 9 0 4 0 1 0.2833333333333333 8 0 0 0 0
本命の PDF レポート（collectl.plot.pdf）を確認します。良い感じです。
PDF レポートの読み方
横軸は時間です。0.05 時間で 3 分、0.25 時間で 15 分と読めます。
CPU usage
#CPUは core 数だと 物理 8core を超えた 10 を記録しているため違うようです。正確な情報が見つけられませんでした。
Memory usage
メモリ使用率はそのまま読めば良さそうです。シーケンスデータが小さいこともあり、最大でも 1.5GB しか使っていませんでした。CloudWatch でモニタリングするならカスタムメトリクスの設定が必要になるのでこれは便利です。
I/O usage
ディスク I/O は最初にいっときアクセスあった以外は思いの他ありませんでした。
まとめ
今回の検証では、Apptainer コンテナ上で Trinity の--monitoringオプションを使用し、リソース使用率を記録ができました。実行結果からは、CPU、メモリ、ディスク I/O の使用状況を把握でき、特にメモリ使用率が低かったことが確認できました。
おわりに
リソース使用率の把握はアプリケーション実行の最適化（解析時間の短縮、コスト削減）に役立ちます。今後も検証し、Trinity の実行を AWS 上で最適化にするのにはどうしたらよいか考えていきます。
